What the bug is. The PR enables exactOptionalPropertyTypes: true globally and updates nearly all optional properties to use prop?: T | undefined syntax. However, three hand-written SDK files were missed: (1) CreateTaskServerContext and TaskServerContext in packages/core/src/experimental/tasks/interfaces.ts still have requestedTtl?: number (no | undefined); (2) TaskRequestsCapability in an internal helpers file still has all nested optional properties without | undefined; (3) MessageExtraInfo in packages/core/src/types/types.ts still has authInfo?, closeSSEStream?, closeStandaloneSSEStream?, and requestInfo? without | undefined. In each case the author worked around the type error rather than fixing the source type, which is precisely what the PR description says it avoids.\n\nSpecific code paths triggered. For (1): in mcp.ts:1133, the expression ctx.task?.requestedTtl evaluates to number | undefined because TaskContext.requestedTtl was correctly updated to number | undefined in taskManager.ts and the optional-chaining ctx.task?. can itself return undefined. Under exactOptionalPropertyTypes, this value cannot be assigned to CreateTaskServerContext["task"].requestedTtl (which accepts number or absent, but not explicit undefined), forcing the as CreateTaskServerContext["task"] cast. For (2): this._serverCapabilities?.tasks?.requests is inferred by Zod v4 as { tools?: { call?: object | undefined } | undefined }, but TaskRequestsCapability lacks the | undefined additions, so client.ts:714 and server.ts:425 cast with as Parameters<typeof assertToolsCallTaskCapability>[0]. For (3): options?.authInfo evaluates to AuthInfo | undefined but MessageExtraInfo.authInfo only accepts AuthInfo (or absent), forcing at least three ...(x === undefined ? {} : { x }) conditional spreads in streamableHttp.ts.\n\nWhy the code does not catch it. The TypeScript compiler accepted the PR because the as casts and conditional spreads suppress the type errors at call sites. The compiler has no way to flag that the root cause—the missing | undefined annotations in the source types—went unaddressed. There is no lint rule or test that verifies source type definitions are fully updated.\n\nImpact. First, the PR description explicitly states "Fix types, not call sites" and "No conditional spread patterns were introduced," both of which are violated. Second, CreateTaskServerContext and TaskServerContext are exported public interfaces; downstream users building CreateTaskServerContext-typed objects with a potentially-undefined requestedTtl will get type errors under exactOptionalPropertyTypes, defeating the PR's purpose. Third, MessageExtraInfo is used in the Transport.onmessage callback signature, which third-party transport implementors must implement; they will face the same exactOptionalPropertyTypes violations when constructing MessageExtraInfo objects. Fourth, the as casts in client.ts and server.ts are wider than necessary (casting to Parameters<...>[0] rather than the specific type), making future refactors fragile.\n\nHow to fix it. (1) In interfaces.ts, change requestedTtl?: number to requestedTtl?: number | undefined in both CreateTaskServerContext.task and TaskServerContext.task. (2) In helpers.ts, add | undefined to all optional nested properties of TaskRequestsCapability, e.g. tools?: { call?: object | undefined } | undefined. (3) In types.ts, add | undefined to authInfo?, closeSSEStream?, closeStandaloneSSEStream?, and requestInfo? in MessageExtraInfo. After each fix, the corresponding as cast or conditional spread can be removed.\n\nStep-by-step proof for bug 003. Suppose ctx.task is { store: s, requestedTtl: undefined } (a TaskContext where requestedTtl was never set, so it is undefined). The expression ctx.task?.requestedTtl evaluates to undefined. Without the as cast, TypeScript under exactOptionalPropertyTypes would refuse to assign { store: s, requestedTtl: undefined } to CreateTaskServerContext["task"] because that type declares requestedTtl?: number (meaning the property may be absent or number, but never explicitly undefined). The cast suppresses this error. The analogous proof applies to bugs 004 and 005 by substituting the Zod-inferred | undefined types vs. the hand-written types.

What the bug is and how it manifests

The Server constructor was refactored from:
super({ ...options, tasks: extractTaskManagerOptions(options?.capabilities?.tasks) });
to:
const tasks = extractTaskManagerOptions(options?.capabilities?.tasks);
super({ ...options, ...(tasks === undefined ? {} : { tasks }) });

This conditional spread is the root cause. When capabilities.tasks is not set, extractTaskManagerOptions returns undefined, so the conditional spreads an empty object, leaving any options.tasks value passed directly via ProtocolOptions (which ServerOptions inherits) to flow through to Protocol unchanged.

The specific code path that triggers it

ServerOptions inherits from ProtocolOptions, which now has tasks?: TaskManagerOptions | undefined. A user who sets the tasks field directly on their ServerOptions without also setting capabilities.tasks will have their task store silently activated. The old code always explicitly overrode this field, ensuring Protocol only ever received a TaskManager derived from the advertised capabilities.

Why existing code does not prevent it

While assertTaskHandlerCapability guards some specific task-operation entry points by checking capabilities.tasks.requests, it does not prevent TaskManager initialization itself. When options.tasks flows through to Protocol, a live TaskManager with a real taskStore is constructed and binds task-related request handlers (tasks/list, tasks/get, etc.). This creates a split: the capability advertisement says no task support, but internal handler registration says otherwise. The refutation argues assertTaskHandlerCapability prevents exploitation, but having an initialized TaskManager in an inconsistent state is itself a semantic regression, regardless of whether every code path is individually guarded.

Why the conditional spread was not needed

The PR description explicitly states: "No conditional spread patterns were introduced". This commit directly contradicts that claim. Since the PR also adds | undefined to ProtocolOptions.tasks in protocol.ts, writing tasks: extractTaskManagerOptions(...) (which can return undefined) is now valid under exactOptionalPropertyTypes. No workaround was required. The Client class does not use a conditional spread for its task initialization, demonstrating that the simpler pattern is sufficient.

Step-by-step proof

1. User constructs: new Server(info, { tasks: { taskStore: myStore } }) — no capabilities.tasks set.
2. extractTaskManagerOptions(options?.capabilities?.tasks) -> extractTaskManagerOptions(undefined) -> returns undefined.
3. OLD code: super({ ...options, tasks: undefined }) — options.tasks is overridden with undefined. Protocol receives tasks: undefined -> NullTaskManager used. Correct behavior.
4. NEW code: ...(undefined === undefined ? {} : { tasks }) spreads {} — options.tasks = { taskStore: myStore } passes through unchanged. Protocol receives tasks: { taskStore: myStore } -> new TaskManager({ taskStore: myStore }) is constructed and binds handlers. Incorrect behavior.
5. The server now has an active task store with no advertised task capability, a semantic inconsistency introduced for no type-safety benefit.

How to fix it

Replace the conditional spread with the original pattern:
super({ ...options, tasks: extractTaskManagerOptions(options?.capabilities?.tasks) });
This compiles correctly under exactOptionalPropertyTypes because ProtocolOptions.tasks is now TaskManagerOptions | undefined.